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SiMB Useful Definitions: 



The following is an explanation of the symbols that will be used throughout 
this document to describe the operation of the various firmware commands. 



•O*: The bracket symbols mean that the information inclosed within them is 
manditory. 

•[,]': The square bracket symbols mean that the information inclosed within 
them is optional. 

• I ' : The vertical bar symbol is used to indicate an alternative or "OR" 
condition. For example, A IB can be thought of as "Either A or B". 



'::=*: This symbol is used to indicate a definition or equivelence. 

'{,}•: Curly brackets are used to denote commemnts. 

• + • : The plus sign is used as an addition symbol or logical or'ing. 

•$• : The dolar sign is used to indicate that a value is radix 16 {in other 
words, the number is in hexadecimal}. Values that are not preceded by 
•$• are assumed to be decimal. 



•NULL": This key word indicates the empty set, or in some coses the fact that 
the function whose value is NULL can be ignored. An example is: 



Argle^Bargle : : = <NULL> 
Essentially you can forget that Argle_Bargle exists for this context. 
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Command Types: 

Widget commands are broken up into 3 categories: 

1. Profile commands 

These commands are used emulate a Profile mass storage device and 
provide for downward compatibility. 

2. Diagnostic commands 

These commands are used to seperate the various subfunctions of the 
drive and provide a means to troubleshoot a Widget without the 
controller of performing any retrying of it's own. 

3. System commands 

These coiranands are used to operate a Widget at it's maximum efficiency. 
Blocks are transfered logically in a multiple block fashion, up to 255 
blocks. 
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ProFile Commands: 

Widget is designed to be backwards compatible with the current ProFile 
Driver, and to that end there exists the three ProFile System commands {Read, 
Write, and Write_Verify} within the firmware. 

Opcode Definition 

$00 Read Logical Block 

$01 Write Logical Block 

$02 Write^Verif y Logical Block 



The three ProFile commands behave in exactly the same fashion as do the 
corresponding instructions on ProFile, with one small exception: the Read 
Logical command does not include information concerning Retry Count or Sparing 
Threshold {however, because of a side effect in the way that the 
Host/Controller interface was designed, the Host may write as many command 
bytes to the controller as it chooses. The Controller will only decode the 
first four. }. The form of each command is: 

<$00l$01|$02> <3 bytes of Logical Block Address) 

There are two 'special' logical address defined in the ProFile protocol, 
namely $FFFFFF {-1} and $FFFFFE {-2}. Logical address (-1) returns as it's 
value Device_ID {as explained under the section titles Diagnostic Commands} 
and logical address (-2) returns as it' s value Widget's spare table structure 
in it ' s raw form. 

It should be noted that if at any time ^i6QBt can not pass it's self test that 
it will refuse to communicate via logical commands {both ProFile and System 
type commands}; Widget will respond to Diagnostic commands at all times, 
however. 



The rest of the commands available on Widget are a complete departure from 
the way that ProFile was implemented. The new form of any command is: 

( <Command_Byte> 
<Instruction_Byte> 
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[ Instr uction_Par araeter ] 
<CheokBy^e> ) 

Command_Byte : : = <CommanclType_Nibble + CommandLength_Nibble> 
CommandType^Nibble ::= <Diagnostic_Command|System_Command> 
Diagnostic_Command ::= <$10> 
System^Command : : = <$20> 



CommandLength^Nibble : : = <Count of all the bytes in the coiwnand string NOT 
including the first one. For example^ the command string to read 
DeviceJD is: ( <$12> <$00> <$ED> ). The commandlength^nibble in this 
case is 2. > 



System_Command ::= <Sys_Read|Sys_Write|Sys_WrVer> 

Diagnostic_Command ::= ( <Read_ID| 

Read_Controller_Status j 
Read_Servo_Status | 
Send_Servo_Command | 
Send^Seek | 
Send_Restore | 
Set_Recovery | 
Soft_Reset| 
Send^Parkl 
Diag_Read| 
Diag_ReadHeader | 
Diag^Writel 
Auto_Offset| 
Read_SpareTable | 
Write_SpareTable j 
Format_Track| 
Read_Abort_Stat| 
Reset_Servo! 
Read_Track | 
Write_Track> ) 

Instruction_Parameter : : = { This value is instruction dependent^ and will 
be formally defined at the same time as the individual instructions } 



CheckByte : : = { This byte is the ones-complement of the sum in MOD-256 
arithmetic, of all the bytes in the instruction string including t\\B 
Command_Byte. } 
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Diagnostic^Comnands: 

Widget's personality^ or manner in which it behaves in a specific Host 
environment, can be thoght of as having two distict parts: 1) that portion that 
is dictated by the hardware and 2) that portion that is controlled by the 
firmware. As trite as that last statement may seem the fact remains that the 
part of Widget that is the hardware is notr easily molded to adapt to different 
conditions. The same is true, but not quite in the same manner, for the 
firmware: the code is locked in a ROM of some sort and costs a lot to change. 
How then can Widget 's "personality" be changed {on-the-fly} to "adapt" to a new 
environment? The answer in thjis case was to architect the firmware in a 
layered fashion: build the intelligence required to operate Widget in it's 
normal system mode from a pool of discrete, primitive functions; these 
primitive functions having just one specific task that they are capable of 
completing. The implication of this architecture is that with very little 
effort these same primitive functions are available to the Host system. 
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Read ID 



Read.ID : : = <$00> 

Instruction Parameter : : = <NULL> 



This diagnostic command requires Widget to deliver to the host some device 
specific information. The structural layout of the data returned is: 



STRUCTURE Identity_Block 

This identity block is defined by the data structures contained within it; 
you will note, however, that a comment is given explaining the type of 
structure for a given element and range of bytes - if the structure is thought 
of as a linear array of bytes - that include the structure. An example is 
NameString. It is a 13-character ascii string, and is located in bytes $0: C. 

NameString : := <Lisa/Nisha2 {13 bytes/$0:G; Ascii String}> 
Device_Type : := <$000110 {3 bytes/$D:F}> 
Firmware_Revision : : = <{2 bytes/$10: 11}> 
Capacity : : = <$9836 {3 bytes/$12: 14}> 
Bytes_Per_Block : := <532 {2 bytes/$15: 16}> 
Number_Of .Cylinders : : = <610 {2 bytes/$17: 18}> 
Number_Of_Heads : := <2 {1 byte/$19}> 
Number_Of_Sectors : : = <32 {1 byte/$1A>> 

Number_Of_Possible_SpareBlocks : : = <$00004C {3 bytes/$1B: 1D}> 
Number_Of_SpareBlocks : : = <{3 bytes/$1E: 20, range 0. .$4B}> 
Number_Of_BadBlocks : := <{3 bytes/$21:23, range 0. .$4B}> 
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Read Control ler Status 



Read Controller Status ::= <$01> 



Every time an operation completes {normally or abnormally} Widget will 
return Standard_Status. This allows the Host system to change it's flow of 
execution based on the state of the value returned in the Status. Normally^ 
Standard_Status is all that is necessary to ensure continuous operation. In 
the exceptional case, or when the Host system is emulating the controler's 
functions, additional information concerning the state of Widget is mandatory: 
without it the Host simply could not make an optimum choice in deciding a 
course of action. 

Controller_Status Is then a means for the Host system to interrogate Widget 
further. Each Status {with the exception of Abort_Status, which is a seperate 
cofimand and is discussed later in this document} belongs to a homogeneous data 
structure: namely a four byte quantity containing a bit map representing the 
various exceptional conditions thyat are available as the first four bytes 
read from the controller upon completion of the current command. 

There are eight status* available to the Host system. The Host requests a 
specific status by setting the Instruction_Parameter to the value 
corresponding to the status needed. 

IF (Instruction_Byte = Read_Controller_Status) 
THEN Instruction_Parameter ::= (<Standard_Status| 

Last_Logical_Block | 
Current_Seek_Address I 
Current_Cylinder | 
Internal^Status | 
State_Registers | 
Exception_Registers | 
Last-Seek_Address>) 

The four byte response to each of the above status requests is of the form: 
Status^Response ::= (<ByteO> <Byte1> <Byte2> <BytG3>) 



Page 9 



Standard Status : : - <$00> 



ByteO : : = < Bit7: Other than $55 response from Host 

Bit6: Write Buffer OverFlow 

Bit5: {not used} 

Bit4: {not used} 

Bit3: Read Error 

Bit2: No Matching Header Found 

Biti: Servo Error 

BitO: Operation Failed > 

Bytel : : = < Bit7: {not used} 

Bit6: Spare Table OverFlow 

BitS: 5 or Less Spare Blocks Available 

Bit4: {not used} 

Bit3: Controller SelfTest Failure 

Bit2: Spare Table has been Updated 

Biti: Seek Error 

BitO: Controller Aborted Last Operation > 

Byte2 : : = < Bit7: First Status Response since Power-On 

Bit6: Logical Block Number Out of Range 
BitS: : {not used}> 

ByteS : : = < Bit?: Read Error Detected by Ecc circuitry 

Bit6: Read Error Detected by Ore circuitry 

BitS: Header timeout 

Bit4: {not used} 
Bit3:0 : Number of unsuccessful retries {out of 10}> 
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Last_Logicai_Block : : = <$01> 



ByteO 
Bytel 
Byte2 
Byte3 



= {not used} 

= <Most Significant Block Adclress> 

= <Next Most Significant Block Address> 

= <Least Significant Block Address> 
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Current Seek Address : : = <$02> 



ByteO 
Bytel 
Byte2 
Byte3 



= <Most Significant Cylinder Address> 
= <Least Significant Cylinder Address> 
= <Head Address> 
= <Sector Address> 
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Current_Cylinder : : = <$03> 



ByteO 
Bytel 
Byte2 
Byte3 



= <Most Significant Cylinder Address> 
= <Least Significant Cylinder Address) 
= <Head Address> 
= <Sector Address> 
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Internal Status : : « <$04> 

ByteO : : = <Bit7: Recovery On 

Bit6: Spare Table Almost Full 

Bit5: Buffer Structure is Contaminated 

Bit4: Power reset has just occured 

Bit3: Current Standard Status is non-zero 

Bit2: 1 : {not used} 

BitO: Controller LED is on> 

Bytel ::= <Bit7: Gn^Track 

Bit6: Read Headers after data recal 

Bit5: Current operation is a write operation 

Bit4: Heads are parked 

Bit3: Sequential look-ahead table search 

Bit2: {not used} 

Bit1: Seek_Complete 

BitO: Auto^Off set is 0N> 

Byte2 : : = {this status is valid ONLY after a ProFile or System Command} 
<Bit7: Seek^Needed 
Bit6: Head_Change_Needed 
Bit5: 2 {not used} 
Biti: Current block is a BAD block 
BitO: Current block is a SPARE block> 

Byte3 ::= <SpareTable_Type|UserData_Type> 
SpareTable^Type : : = <$08> 
UserData^Type : : = <$02> 
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State_Registers : : = <$05> 
ByteO : : = {not used) 



Byte1 : : = <Bit7: 
Bit6: 
Bits: 
Bit4: 
Bit3: 
Bit2: 
Biti: 
BitO: 



Ram_Failure 

Eprom_Failure 

Oisk_Speed_Failure 

Servo_Failure 

Sector_Count_Failure 

State_Machine_Failure 

Read_Write_Failure 

No_SpareTable_Found> 



Byte2 : : = <Bit7: Disk Read/-Write 

Bit6: SioRdy 

BitS: Msell 

Bit4: MselO 

Bit3: Bay 

Bit2: Cmd 

Biti: EccError {active low} 

BitO: Start {active low}> 

Byte3 : : = <Bit7: CrcError {active low} 

Bit6: Write_Not_Valid {active low} 

BitS: ServoReady 

Bit4: ServoError 

Bit3: : Current state of the state-machine) 
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Exception_Registers : : » <$06> 

ByteO : : = <Bit7: Read error 

Bit5: Servo error while reading 

BitS: At least one successful read in last retry sequence 

Bit4: Header Timeout 

Bit3: CrcError or EccError 

Bit2:0 : {not used}) 



Bytel : : = <Bit7 
Bite 
Bits 
Bit4 



= EccError 
= CrcError 
= Header Timeout 
= {not used} 



Bit3:0 : {number of bad retries out of 10}> 

Byte2 : : = <Bit7: Write Error 

Bit6: Servo Error while writing 

BitS: At least one sucessf ul write in last retry sequence 

Bit4: Header Timeout 

BitS: : {not used}> 

ByteS ::= {number of bad retries out of 10} 
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Read Servo Status 



Read_Servo_Status : : = <$02> 
Instruction^Parameter : : = <0. . 8> 

This status command is used to interrogate the Servo Processor in much the 
same way that Read_Controller_Status is used. In fact, the form of the result 
is the same four byte-mapped quantity. 

This coiwnand is of the particular value to a diagnostician that is interested 
in 'scoping-out' the servo subsystem. 

A more complete description of the servo commands can be read in the document 
titled "Widget Servo Functional Objective" written by Jim Reed. 
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Sencl_Servo_Commanci 

Send_Servo_Co[ranand : : = <$03> 
Instruotion^Parameter ::= (<ByteO> <Byte1> <Byte2> <Byte3>) 

Normally, the Host will allow the controller to manipulate the servo 
processor in order to perform useful work. For example, let's suppose that the 
Host system wishes to move drive's heads from one track to another. Under 
normal operating conditions the preferred way to perform this task is to use 
the Send_Seek command {explained later}. However, the Host has the capability 
to bypass the controller and direct the servo processor. Indeed, the Host can 
issue the servo command to position the heads so that the seek is completly 
transparent to the controller. The implication of this command is that the Host 
can gain even more control of the system if it so chooses. 

A more complete description of the servo commands can be read in the document 
titled "Widget Servo Functional Objective" written by Jim Reed. 

ByteO : : = <S_Command + S_Direction + Hi_Magnitude> 

S^Command : : = <Offset| 

Diagnostic! 
DataRecal | 
BrakeReleasel 
Access I 

Access_Offset| 
Home> 

Offset ::= <$10> 
Diagnostic : : = <$20> 
DataRecal : : = <$40> 
BrakeRelease : : = <$70> 
Access : : = <$80> 
Access_Of f set : : = <$90> 
Home::=<$CO> 

S^Direction ::= <Positive|Negative> 

Positive : : = <$08 {towards inside diameter}) 
Negative : : = <$00 {towards outside diameter}) 

Hi^Magnitude : : = <0, . 3 {move heads in multiples of 256} > 

Bytel : : = <LowJ1agnitude : : = 0. .255> 

{note: Hi_magnitude^ Low_magnitude, and S_Direction establish 
the relatiye distance the heads must move to arrive at the 
target track} 
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Byte2 : : = <0f f set_Direction + Auto_Of f set_Switch + Of f set_Magnitude> 

Offset_Direction ::= <Positive|Negative> 

Positive : : = <$80 {towards outside diameter}> 
Negative : : = <$00 {towards inside diameter}> 

Auto_Offset_Switch ::= <ON|OFF> 

ON : : = <$40 {assert fine positioning}> 
OFF : : = <$00> 

Of f set_Hagnitude : : = <0. . 32> 

Byte3 : : = <StatusRquest> 
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Send Seek 



Send_Seek : : = <$04> 

Instruction_Parameter : : = (<HiCyl> <LoCyl> <Head> <Sector> <AutOf fsetFlag>) 

HiCyL LoCyL Head, Sector : : = <$00. . $FF> 
AutoOffsetFlag := <ON|OFF> 

ON ::= <$01> 

OFF : : = <$00> 

Widget's Send_Seek command allows the Host system to place the heads over any 
track on the disk. The value of the seek address is sent as the 
Instruction_Parameter, and each parameter is a byte in length. For example, 
for the Host to seek to (Cylinder 1, Head 0, Sector 18) without AutoOffset a 
seek command would be issued with the following Instruction_Parameter: ($0000, 
$00, $12, $00). 
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Send_Restore 

Send_Restore : : = <$05> 

Instruction^Parameter ::= <DataRecal|BrakeRelease> 
DataRecal : : = <$40> 
BrakeRelease : : = <$70> 



The Send_Restore command is used by the Host to initialize the servo 
processor and to put the heads in a known location. This command is the same as 
performing a Data/Format Recal except that the controller updates it's 
internal state to account for the new servo position. 
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Set_Recovery 



Set_Recovery : : = <$06> 

Instruction_Parameter : : = <ON|OFF> 

ON ::= <$01> 
OFF : : = <$00> 



The exception handling characteristics of Widget approximate a binary set: 
either Widget handles everything, or the Host system does. The command 
'Set_Recovery* is the Host's link with this protocol in that it is through this 
instruction that the Host can gain control of the media. When Widget comes up 
after being reset, it assumes control and sets ffeco^ery to be ON. The Host 
system must overtly change this state if it wishes to emulate a different 
exception handling criteria. Once Recovery is OFF, the controller will always 
fail in an operation if an exception occurs: the Host j/?ast assume 
responsibility for ALL error handling. 
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Soft Reset 



Soft^Reset ::= <$07> 
Instruction Parameter : : = <NULL> 



This command instructs the Widget firmware to restart its flow of execution 
at its initialization point. The results should be the same as a power reset. 
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Send Park 



Send_Park ::= <$08> 
Instruction Paramter ::= <NULL> 



When the Host issues a Send^Park command to the controller the results are 
that the heads are moved off the data surface and held very near the inside 
diameter crash stop. The difference between this command and the 
Send_Servo_Command: Home^ is that Home is performed 'open-loop* with the crash 
stop as its reference point, while Send_Park is an access command to a specific 
track. The net result is a fairly hefty savings of time. 
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Diag_Reacl 



Diag^Read : : = <$09> 
Instruction_Parameter ::= (<SGCtor><SGq\/aluG>) 

Sector ::= (<0..31» 

SeqValue ::= (<NewSector|IncSector><Long>) 

NeuiSector : : = $80 {selects 'Sector* as the sector to be operated on} 
IncSector : : = $40 {increments the last sector value} 
Long : : = $20 {if Long then the ECC syndrome will be ignored and the 
checkbytes will be included at the end of the data} 

The Diag_Read command is used to read the block on the disk pointed to by the 
last seek address. The form of the returned data is exactly the same as that of 
ProFile_Read or Sys_Read in that 4 bytes of Standard_Status precede the block 
of data. 
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Diag_ReaciHeacler 



Diag^ReadHeader : : = <$0A> 
Instruction_Parameter ::= (<Sector><Seq\/alue>) 

Sector ::= (<0..31>) 

SeqValue ::= (<NGwSGCtor|IncSector><Long>) 

NewSector : : = $80 {selects •Sector* as the sector to be operated on} 
IncSector : : = $40 {increments the last sector value} 
Long : : = $20 {if Long then the ECC syndrome will be ignored and the 
checkbytes will be included at the end of the data} 



When the heads are positioned over an unknown location^ or when it is 
suspected that a block's header is shot^ it is time to use the Diag_ReadHeader 
command. This instruction allows the host to "suck-up' both whatever 
information is residing in the block "s header field as well as the data from 
the block. The form of the result is: 



Result ::= (<Header {bytes/$00: 05}> 
<Gap {bytGS/$05: 0C}> 
<Data{bytes/$0D:21F}» 

Header ::= (<HiCyl> <LowCyl> <HdSct> <-HiCyl> <-LowCyl> <-HdSct>) 



HiCyl : 
LowCyl 
HdSct : 



-HiCyl : 
-LowCyl 
-HdSct : 



= <Most significant byte of cylinder address> 
: = <Least significant byte of cylinder address> 
= <Bit7:6 : Head address 

Bit5: : Sector address> 

= < ones -complement of HiCyl> 
; = <ones-complement of LowCyl> 
= < ones -complement of HdSct> 



Gap : : = <$00> 
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Diag_Wrlte 

Diag^Write : : = <$0B> 

Instruction_Parameter : : = <NULL> 

Sector ::= (<0..31» 

SeqValue ::= (<NewSector|IncSector><Long>) 

NewSector : : = $80 {selects 'Sector' as the sector to be operated on} 
IncSector : : = $40 {increments the last sector value} 
Long : : = $2(^ {if Long then the ECC checkbytes are to be supplied at the 
end of the write data} 

This instruction allows the Host to write a block of data to the location on 
the disk pointed to by the last seek address. Diag_Write is valid for all 
states that the controller may wid up in, but is recommended that a Send_Seek 
coiranand precede the write command to ensure that the correct block will be 
written. 
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Auto Offset 



Auto_Of f set : : = <$0C> 

Instruction_Parameter : : = <NULL> 

This command is used by the Host to fine-position the heads after they are 
on-traok. The auto_offset function can also be implemented by using the 
Send_Servo_Command instruction; the difference is that the controller will 
update some internal information {remember, servo commands are transparent} as 
well as select the correct head to offset off of {the Widget system uses head 1 
only for fine positioning}. 
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Read_SpareTable 



Read_SpareTable : : = <$0D> 

Instruction_Parameter : : = <NULL> 

Reading {and writing} the Widget's sparetable is an absolute must for 
diagnostic purposes, and if the Host wishes to emulate the controller. The 
result of this instruction is identical to performing a ProFile_Read from 
block -1 {$FFFFFE} and has the form: 

Result : : = (<Fence {bytes/$00: 03}> 

<RunNumber {bytes/$04: 07}> 
<Format_Offset {byte/$08}> 
<Format_InterLeave {byte/$09}> 
<HeadPtr_Array {bytes/$OA: 49}> 
<SpareCount {byte/$4A}> 
<BadBlockCount {byte/$4B}> 
<BitMap {bytes/$4C: 55}> 
<Heap {bytes/$56: 185}> 
<InterLeave_Map {bytes/$186: 1A5}> 
(Checksum {bytes/$1A6: 1A7}> 
<Fence {bytes/$1A8: 1AB}> 
<Zone_Table {bytes/$1AC: 1C1}> 
<Fence {bytes/$200: 203}> ) 

Fence : := «$F0> <$78> <$3C> <$1E> ) 

RunNumber : : = <32-bit integer > 

This integer is incremented once each time the spare table is written to 
to the disk. Because two copies are kept on the the disk, the RunNumber is 
used to indicate which is the more recent of the two, should both 
copies not be updated. 

Format_Of f set : : = <0- . NumberOf Sector s> 

Format_Off set is the number of physical sectors there are from index 
mark until logical sector 0. 

Format_InterLeave : : = <0. . 6> 

This number is the interleave factor for this disk and is used in 
calculating where each of the logical sectors are relative to actual 
sector locations. 

HeadPtr_Array : : = <ARRAYlO. .63] of HeadPtr 

HeadPtr : : = <Nil+Ptr> 

Nil : : = <$80 {if Nil the end-of-chain}> 
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Ptr : : = <$00. . $7F {address of next element}> 

A Ptr is a 7-bit structure that 'points' to a 
specific location within the Heap. To arrive 
at the actual index value within the Heap, 
the Ptr must first be multiplied by 4 {the 
length of each element}. 

When a disk is formatted and being written to for the first time, each logical 
block is assigned the first available physical block on the disk. Therefore you 
would expect that LogicalBlock(O) would occupy PhysicalBlock(O), L(1) — > 
P(1), etc. There are instances, however, when a block of data must be relocated 
to anaother space on the disk that does not follow the original progression 
(for example, the original space was defective). In order to 'find' these 
relocated blocks in the future a record must be kept as to where all these 
relocated blocks have been put. This record takes the form of 128 linked lists 
having the f orm: 

HeadPtr[n] —> LinkedList[n], where n ::= [0..127] 

The algorithm for deciding whether or not a logical block has been relocated 
is to extract bits 10: 16 from the LogicalBlockNumber and use it as an index 
into the HeadPtrArray: 

IF (HeadPtr [LogicalBlockNumber /bits 10: 16]. Nil) 
THEN LogicalBlock has not been relocated 
ELSE use HeadPtr []. Ptr to begin searching the chain for a matching 

element {refer to the structure of ListElement for more detail} 
IF no matching ListElement 
THEN LogicalBlock has not been relocated 

ELSE the element position in the Heap corresponds to the new 
physical block location 

SpareCount : : = <$00. . $4B> 

BadBlockCount : : = <$00. . $4B> 

Bittiap : : = <ARRAY[$00. . $4B] of Bits> 

The bit map is used to keep a record of which spare blocks are 
occupied. 

Heap : : = < ARRAY [$00. . $4B] of ListElement> 

ListElement : : = (<Nil+Used+Useable+Spr_Type+Data_Type> 
<Token> 
<Ptr>) 

Used : : = <$40> 

Useable : : = <$20> 

Spr_Type ::= <Spare|BadBlock> 

Spare ::= <$10> 

BadBlock : : = <$00> 
Data_Type ::= <Data|SpareTable> 

Data : : = <$02> 
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SpareTable : : = <$08> 

Token : : = <Bits 0: 9 of LogicalBlock> 

InterLeave^Map ::= <ARRAY[0. .31] of [0..31]> 

The InterLeave_Map is used to logical re-interleave the drive so that 
Widget can be run optimally on any system without having different 
manufacturing or formatting processes. 

Check_Sum : : = <sum of all bytes in the spare table from the first fence to 

beginning of this structure^ in MOD-65536 arithmetic> 

Zone_Table : : = <ARRAY[0. .NumberOf Zones] of Zone_Element> 

Zone_Element : : = <0f f set_Direction+Of f set_Magnitude> 
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Write_SpareTable 



Urite^SpareTable : : = <$0E> 

Instruction^Parameter ::= «$F0> <$78> <$3C> <$1E» 

This command allows the Host to 'force" a new spare table on the controller, 
and is executed just like any of the other write commands (data, in this case, 
HUST conform to the structure presented in Read_SpareTable}. The data sent to 
the controller is written to the two spare table locations on the disk. 



Page 32 



Format_Track 

Format_Track : : = <$0F> 
Instruction^Parameter : : = (<PassWord>) 
Password : : = (<$F0> <$78> <$3C> <$1E» 
The format command is used to: 

1. Operate on the track that is currently beneath the heads - this 

implies that the Host had best perform a Send_Seek and Auto_Off set 
command prior top formatting a track. 

2, New headers will be layed down in every sector of the track. 
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Read Abort Status 



RGad_Abort_Status ::= <$11> 
Instruction Parameter : : = <NULL> 



Read_Abort_Status will return vaild data only AFTER the controller has 
aborted (identified by Standard_Status.Byte1.BitO}. The form of the result is 
a 16 byte string, and its contents are the contents of the controller's 
registers at the time of the abort - with the exception of byte $0F, which is 
the value of the Abort taken. 
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Reset Servo 



Reset_Servo : : = <$12> 

Instruction_Parameter : : = <NULL> 

Reset_Servo allows the Host to initialize the servo processor without having 
to power the device down. The controller will automatically reset the Servo, 
set the baud rate at 57, 6K, and check for valid initial conditions. 
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Read_Track 

Read^Track : : = <$13> 
Instruction_Parameter ::= (<Sector><SeqValue>) 

Sector ::= (<0. .31>) 

SeqValue ::= (<NewSector|IncSector><Long>) 

NewSector : : = $80 {selects 'Sector' as the sector to be operated on} 
IncSector : : = $40 {increments the last sector value} 
Long ::= $20 {if Long then the ECC syndrome will be ignored and the 
checkbytes will be included at the end of the data} 
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Write_Track 

•rite^Track : : = <$13> 
Instruction_Parameter ::= (<Sector><Seq\/alue>) 

Sector ::= (<0. .31>) 

SeqValue ::= (<NewSector|IncSector><Long>) 

NewSector : : = $80 {selects 'Sector' as the sector to be operated on} 
IncSector : : = $40 {increments the last sector value} 
Long : : = $20 {if Long then the ECC checkbytesare to be supplied at the 
end of the write data} 

This diagnostic cornmand is used mainly to facilitate the Nisha FST program. 
The entire track (as defined by the last Seek address^ and beginning with 
Sector or Last_Sector + 1 if NewSector or IncSector is set) is written. Data, 
however is sent for only the first sector written (implying that the whole 
track will be written with the same data pattern). This diagnostic command is 
used mainly to facilitate the Nisha FST program. 
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System Commands: 

System commands have been implemented for essentially two reasons: 

1 . It was important for Widget to add one more check on the CMD/BSY 

handshake: namely the addition of a checkbyte following the command 
string- 

2. In order to increase the performance of the system without modifying 

the hardware it was critical to introduce another level of parallelism 
into the Host/Controller interface. Most of the reads for a specific 
block on the disk are followed by a read for the next logically sequential 
block. Therefore the command decoding and checkbyte comparison for all 
but the first block has been suppressed into a multiblock-type command. 
The implementation for this added parallelism is to send an extra 
parameter with the (first) LogicalBlock indicating the number of blocks 
to be read sequentially. 
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Sys_Read 



Instruction_Parameter : : = (<BlockCount> <LogicalBlock>) 

BlockCount : : = <$01. . $FF> 

This parameter is the number of blocks to be read that follow 
sequentially from LogicalBlock. It is assumed that one block 
(LogicalBlock) will be read. 

LogicalBlock : : = <$000000. . 009835> 
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Sys__Write 



Instruction_Parameter : : = «BlockCount> <LogicalBlock» 

BlockCount ::= <$01..$FF> 

This parameter is the number of blocks to be read that follow 
sequentially from LogioalBlock. It is assumed that one block 
(LogicalBlock) will be read. 

LogioalBlock : : = <$000000. . 009835> 
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Command Summary 

ProFilG_CocMnands: 

ProFile_Read : : = «$00> <3 bytes LogicalBlock>) 
ProFile_Write : : = (<$01> <3 bytes LogicalBlock>) 

Diagnostic_Coinmands: 

Read_Id : : = (<$12> <$00> <$ED>) 

Read_ControllGr ::= «$13> <$01> <StatusRGquest> <CheckByte» 

Read_Servo_Status : : = (<$13> <$02> <StatusRequest> <CheckByte>) 

Send_Servo_Command : : = «$15> <$03> <CofnmandRequest> <ChGckByte» 

Send_Seek : : = (<$17> <$04> <SeekAddress> <AutoOf f set Flag> <CheckByte>) 

Send_Restore : : = (<$13> <$05> < RecalType> <CheckByte» 

Set_Recovery : : = «$13> <$06> <0n/0ff > <CheckByte» 

Sof t_Reset : : = «$12> <$07> <$e6» 

Send_Park : : = «$12> <$08> <$E5» 

Diag_Read : : = «$14> <$09> <Sector> <SeqValue> <CheckByte» 

Diag_ReadHeader :: = (<$14> <$0A> <Sector> <SeqValue> <CheckByte» 

Diag_Write : : = «$14> <$0B> <Sector> <SeqValue> <CheckByte» 

Auto_Offset ::= «$12> <$0C> <$E1» 

Read_SpareTable : : = «$12> <$0D> <$E0» 

Write_SpareTable : : = «$16> <$0E> <PassWord> <CheckByte» 

Format_Track : : = «$16> <$0F> <Pass(lllord> <CheckByte» 

Read_Abort_Status : : = «$12> <$11> <$0C» 

Reset_Servo : : = «$12> <$12> <$DB» 

Read_Track : : = «$14> <$13> <Sector> <SeqValue> <CheckByte» 

Write_Track : : = «$14> <$14> <Sector> <SeqValue> <CheckByte» 

Syst ein_Coinmands : 



Sys_Read : 
Sys_Write 
Sys_WrVer 



«$26> <$00> <BlockCount> <LogicalBlock> <CheckByte» 
= «$26> <$01> <BlockCount> <LogicalBlock> <CheckByte» 
= «$25> <$02> <LogicalBlock> <CheckByte» 



Password : : = «$F0> <$78> <$3C> <$1E» 



Abort Status Variables 



There are occasions when the Nisha Controller will detect that something is 
radically wrong with the Nisha Subsystem, i. e., the ram on board the controller goes 
on vacation, or the positioning system gives up the ghost, etc. In one of these 
cases the controller will abort its current instruction and return control to the 
Host, hopefully with enough information that the Host can make an intelligent 
decision concerning the state of Nisha. 

The Host can read some information concerning the abort that the controller took 
by requesting Read_Abort_Status. This command returns a result that is 20 bytes 
long: 4 bytes of standard status and 16 bytes of abort status. The contents of the 
abort status are dependent upon the actual abort taken, and is determined by 
examining the contents of byte 16: the value of the abort taken. 

$01 : Illegal interface response, or Host Nak 

Byte/$09: Response byte that caused abort 
$02; Illegal Ram Bank select 

Byte/$00: Bank number 
$03: Format Error: illegal state-machine state 

Byte/$OA: state of state-machine at time of abort 
$04: Illegal Rom Bank Select 

Byte/$00: Bank number 
$05: Illegal interrupt or DeadMan_Timeout 

Bytes/$OA: OB: Address of routine at time of timeout 
$06: Format Error: Error while writing sector 

Byte/$09: Error status from FormatBlock 
$08: Correnand Checkbyte Error 

$09: ProFile or System comnand attempted while SelfTest Error 
$0A: Illegal Command 

$0B: Unrecoverable Servo Error while reading 
$0C: Sparing attempted on non-existent spare block 
$0D: Sparing attempted while sparetable full 
$0E: Deletion attempted of non-existent bad block 
$0F: Illegal exception instruction 
$10: Write buffer overflow 
$11: Unrecoverable servo error while writing 
$12: Servo status request sent as Servo command 
$13: Restore Error: Non-Recal parameter 

Byte/$00: Value of illegal parameter sent 
$14: Illegal password sent to Write_SpareTable_Command 
$15: Illegal password sent to Format command 
$16: Illegal format parameters 

Bytes/$09: OA: illegal parameters 
$17: Illegal password sent to Init_SpareTable_Command 
$18: Zero block count sent to System_Command 
$19: Write Error: Illegal state-machine state 

Byte/$OA: State-machine state at time of abort 
$1A: Read Error: illegal state-machine state 

Byte/$OA: State-machine state at time of abort 



$1B: ReadHeader Error: illegal state-machine state 

Byte/$OA: State-machine state at time of abort 
$1C: Request for illegal logical block 

Bytes/$00: 02: logical block number 
$1D: External Stack overflow 

Bytes/$04: 07: stack history 
$1E: Search for SpareTable failed 
$1F: No sparetable structure found in sparetable 
$20: Update of sparetable failed 
$21: Illegal sparecount instruction 

Bytes/$09: value of illegal instruction 
$22: Unrecoverable servo error while seeking 
$23: Unable to transmit command to servo 
$24: Unable to receive status from servo 
$25: Unable to find any headers after DataRecal 
$26: Servo error after servo reset 

Byte/$0A: value of controller status port 
$27: Servo conmiunication error after servo reset 
$28: Scan attempted without sparetable 
$29: Illegal Bank Call 
$2A: Illegal Bank Return 

$2B: Illegal Sector value detected in LocateSector 
$2C: Illef al Sector value detected while remapping 
$2D: Control/Status register in GA is non-functional 
$2E: Read gate not active 
$2F: Read always active 
$30: Statemachine single step error 
$31: Data compare mismatch in r/w self test 
$32: SpareTable Ptr is addressing out-of-bounds 
$33: New Spare not found by Overlap 



